Media Acquisition, Processing and Distribution System for the Internet

ABSTRACT

The present invention, generally speaking, provides a broad-based solution for acquisition, processing and distribution of media objects including pictures (images), movies, videos, graphics, sound clips, etc via the Internet or the like. And specifically, it is a solution to such systems for use in applications wherein there are multiple originators of media objects that will be viewed in multiple web sites having different viewing requirements. A browser-based prepare and post tool prepares and submits media objects from inside a standard browser to a remote server. A Media Acquisition, Processing and Distribution (MAPD) system receives these media objects, processes them to meet specific requirements, and delivers them for integration into remote databases. MAPD system services include media object submission, processing, hosting and mirroring. The hosting service delivers a media object URL to a remote database, allowing the media object to be requested and served by the media object server. The mirroring service delivers the actual media object to multi-point remote databases to be stored and served by the customer.

This application is a continuation of non-provisional application Ser.No. 12/790,442, filed May 28, 2010, which is a continuation ofnon-provisional application Ser. No. 11/935,340, filed Nov. 5, 2007,which is a continuation of U.S. Pat. No. 7,313,604, issued Dec. 25,2007, which is a continuation of U.S. Pat. No. 6,732,162, issued May 4,2004. Each of the applications and patents identified above isincorporated by reference herein, in its entirety, for all purposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to the acquisition, processing anddistribution of media objects on the Internet and, more particularly, tosuch systems for use in applications wherein there are multipleoriginators of media objects that will be viewed in multiple web siteshaving different viewing requirements.

2. State of the Art

Much of the phenomenal success of the Web is attributable to itsgraphical nature. Literally, a picture is worth a thousand words. Thecapture of digital images has become routine, using digital cameras(still and video) and scanners. Nevertheless, although the handling ofimages by Web site creators has achieved a high degree of automation,for the average user manipulating and sharing digital images over theInternet remains a cumbersome and daunting process. Piecemeal solutionsthat have been devised for handling digital images require a level ofsophistication that is beyond that of the ordinary user. Additionally,where automated solutions do not exist, time consuming and error-pronehuman and manual intervention are required to manipulate or shareimages. Such manual intervention for transferring a digital image mayinclude, for example, first downloading a FTP program, then installingit, then running it and connecting it to an FTP server by typing theserver name in the connection dialog, then navigating to the propersubdirectory, selecting the files to be uploaded, making sure that theprogram is in binary transfer mode, then sending the files. For theaverage user, such an involved process is a disadvantage.

Additionally, as technologies advance and casual users begin toexperiment with other image types, such as streaming video, 3D objects,slide shows, movies, and accompanying sound files, the processesrequired to share these rich media types on the Internet becomesexponentially more complicated and prohibitive. As the realization ofthe Internet as an interactive, content rich medium becomes more andmore a reality, the need for enabling the acquisition and distributionof rich content and media on the Internet will become the gating factorto its long-term success.

Once specific application of handling media over the Internet is in thereal-estate market. It has been reported that over 25% of prospectiveresidential home-buyers use the Internet as a means for locatingproperties of potential interest. There are many web sites dedicated tothis purpose, including major real estate portals (e.g., Realtor.com andHomeAdvisor), national and regional brokerages, and individual realtoror broker web sites, to name a few. To be effective, these sites mustprovide rich visual content in the form of images of the propertieslisted. The image content can take the form of a single still image,multiple still images, slide shows comprised of a sequence of stillimages, immersive images (360 degree views), and video tours. Theseimages can also have audio associated with them. The term media objectis used generically herein to refer to all types of such images,including audio and graphic objects.

While anyone can access the Internet through a browser, getting imagesposted to the Internet is a complicated process generally requiring ahigh degree of technical proficiency and specialized software tools. Itis even more difficult when the media objects are of multiple types(still images, immersive images, video, etc.) and are created bydifferent originators. For example, a real estate listing might includean image captured by a multiple listing service photographer, animmersive image captured by a professional photographer, and multiplestill images taken by the real estate agent herself. Add to this thefact that all of these media objects need to be displayed on multipleweb sites that will have different viewing requirements. For example, anational real estate portal may only accept still images of a certainsize and quality, say 300.times.200 pixels at a jpeg compression settingof 60%, while an agent=s individual web site may require a 390.times.260pixel representation of the images at a different quality setting.Additionally, different browser versions have different viewingrequirements for certain media object types. It is apparent that theproblems associated with acquiring media objects from multiple sourcesand distributing them in the required form to multiple destination websites are complex.

There are web sites today that offer a subset of this functionalityspecifically in the on line photo sharing market. These sites allowusers to store their personal photographs, display them in a thumbnailor larger view and invite family and friends to view the pictures. Thesephoto sharing sites let users upload digital pictures directly or havefilm processed and then posted to the web site. The purpose of thesesites is to accommodate image uploads from many users within aproprietary system and where the image destination is intended to staywithin that system.

The present invention teaches a Media Acquisition, Processing andDistribution (MAPD) system that solves many of the problems of handlingmedia over the internet such as encountered in the real-estate marketand photo sharing market. The Media Acquisition, Processing andDistribution (MAPD) system of the present invention has three majorcomponents: (1) media acquisition, (2) media processing and (3) mediadistribution (via hosting or mirroring). The purpose of the MAPD systemis to enable multiple users without computer expertise to easily submitmedia objects that after appropriate processing in accordance withpre-defined requirements, are viewable on multiple web sites.

The MAPD system of the present invention specifically handles imageupload within an open system and that system is designed to process anddistribute media objects outside of itself, to be viewed in multiple websites having different viewing requirements such as desired in thereal-estate market. Additionally, the system of the present invention isdesigned such that the proprietary systems used in the photo sharingsites are unique to each web site and are not designed to be deployedacross several web sites, markets or partners. Finally, the MAPD systemof the present invention is designed to be used by varying and differentweb sites across many markets and partners. One important aspect of theMAPD system is its API or abstraction layer that specifically allowsmultiple web sites to integrate the MAPD system functionality.

SUMMARY

The present invention, generally speaking, provides a broad-basedsolution for the acquisition, processing and automatic distribution ofmedia objects via the Internet in a manner that does not require a highdegree of technical proficiency. Specifically, the present inventionprovides a media acquisition, processing and distribution system formedia objects submitted by multiple users for viewing within a pluralityof destination web sites that have different media object viewingrequirements. The invention provides means for each of the originatorsto associate one or more local media objects with a media objectinterface within a browser. Means are provided for storing informationthat defines the media object viewing requirements for each of thedestination web sites. A remote server or servers receives the mediaobjects from each originator and, based on the information stored in thedatabase, processes the media objects in accordance with the mediaobject viewing requirements of the destination web sites. In a hostingconfiguration, the remote server(s) send a URL to each destination website that links the site back to the processed media object for viewing.In a mirroring configuration, the remote server(s) distribute theprocessed media objects to the destination web site servers.

In accordance with a further aspect of the present invention, within theMAPD client/server architecture, means are provided for intelligentlyprocessing the media objects both on the client and server, therebyenabling a more efficient use of bandwidth.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may be further understood from the following descriptionin conjunction with the appended drawings. In the drawing:

FIG. 1 is a diagram illustrating information flow in accordance with oneaspect of the invention;

FIG. 2 is a more detailed block diagram corresponding to the diagram ofFIG. 1;

FIG. 3 is a diagram illustrating information flow in accordance withanother aspect of the invention;

FIG. 4 is a more detailed block diagram corresponding to the diagram ofFIG. 3;

FIG. 5 is a diagram of an exemplary Web page providing image acquisitionfunctions;

FIG. 6 is a conceptual block diagram of the MAPD system network imagingsystem work flow and media processing engine scalability;

FIG. 7 is a system block diagram of the hardware partition for MAPDsystem network imaging system mirroring service;

FIG. 8 is a diagram showing the relationship of certain areas of themirroring service;

FIG. 9 is a diagram illustrating three-tier partitioning of the networkimaging system;

FIG. 10 is an entity/relationship diagram of the database of FIG. 9;

FIG. 11 is a diagram illustrating relationships between account, serviceand storage entities;

FIG. 12 is a diagram illustrating relationships between mirror serviceentities; and

FIG. 13 is a method called when a new media object arrives at a clientsite.

DETAILED DESCRIPTION

The following description describes a system for MAPD that enables theacquisition, processing and distribution of media objects from multipleusers to multiple viewing web sites on the Internet. The term mediaobject as used herein refers broadly to any form of digital image orgraphical file, including still images, PDF files, video images, audio,slide shows, etc. Although in the following description the submissionand processing of still images is described in greatest detail, the sameprinciples apply equally to media objects of all descriptions and applyequally to groups of multiple images.

The MAPD system of the present invention is for use in thoseapplications wherein multiple users of the system have a need to submitmedia objects for viewing on multiple destination web sites that, ingeneral, have different viewing requirements. The term viewingrequirements refers broadly to the various and unique ways media objectsare displayed by web sites. Each web site places different technicalrequirements and constraints on the way that site uniquely displaysmedia objects and therefore allows for viewing of media objects byvisitors to the site. In accordance with the present invention, meansare provided in the form of a prepare and post tool for each of theoriginators of media objects to associate one or more media objects witha media object identifier on a locally viewable web page, and foruploading the media object or objects to at least one remote server. Adatabase stores information that defines the media object viewingrequirements for each of the destination web sites. Within the MAPDclient/server architecture, either on the client or server, the MAPDsystem processes the input media objects to meet the viewingrequirements that are specified for each of the destination web sites.Such processing may take the form of image resizing, reformatting(changing the file format), encoding in the case of video, specifyingmedia object storage location and browser version support just to name afew. The MAPD system then either delivers a media object URL to thedestination web sites (hosting service) or transfers the processed mediaobjects to the destination web sites ready for viewing (mirroringservice). Specifically, the hosting service delivers a media object URLto a web page, allowing the media object to be requested by a customerweb site and served by the MAPD system. The mirroring service deliversthe actual media object, or other related data such as a media objectURL, to a remote database to be served by the host of the destinationweb site.

Using MAPD system, end users can submit media objects in an immediateand intuitive manner. No technical sophistication is required. Inparticular, understanding technical terms such as JPEG, resolution,pixel, kilobyte, transfer protocol, IP address, etc., is not required,since the MAPD system automatically and transparently handles all ofthese tasks for the end user.

For on-line commerce customers dealing with high transaction load websites, hosting is appealing. The MAPD system hosting service allowsthese customers to incorporate rich media (where rich media can begenerally defined as combinations of different media objects such aspictures, movies, sound clips, etc.) into interactive web sites. TheMAPD system hosting service provides this rich media to web siteswithout requiring that they bear the overhead costs associated withhosting the media objects on their own servers or without the technicalexpertise required to process and create rich media. Referring to FIG.1, the MAPD system hosting service entails the following step-by-stepprocess:

1. A media object is submitted by an end user (originator) draggingcontent into a MAPD system customer's web page. Media object ID data isalso collected.

2. The media object may be pre-processed, such as converted, reduced,enhanced, etc., on the client within the MAPD client/serverarchitecture.

3. The media object is uploaded into the MAPD system with IDinformation.

4. The media object is processed by the MAPD system in accordance with aprofile that represents the requirements of the destination web sites.The requirement data is stored in a database and the media object isstored on a file server.

5. The MAPD system transparently returns a URL (representing the mediaobject location) to the customer's web page. The media object source URLis embedded in the HTML in the customer's web page and returned to thecustomer's web server.

6. A hit by an end user (requester) to the MAPD system customer's webpage where the media object source URL is embedded causes the customer'sserver to request insertion of the media object hosted from the MAPDsystem.

7. The requested media object is served by the MAPD system andintegrated into the customer's web page in real time as the web pagedraws.

8. The end user's (requestor's) browser presents the finished web pageto the end user.

Transaction flow for the host service may be further appreciated withreference to FIG. 2. Transaction flow begins with a MAPD systemcustomer's web page having embedded in it the prepare and post tool. Theprepare and post tool is represented on the web page as a media objectidentifier into which the user drags and drops a selected media object.The media object identifier may take the form of a Java applet, anActiveX control, etc. The function of the identifier is to receive amedia object, display a thumbnail or visual representation of the mediaobject, and (optionally) perform preprocessing of the media object. Aseparate component may be used to upload the media object in response tothe user clicking on a Send button. In an exemplary embodiment, clickingon the Send button activates a COM component of the prepare and posttool, called the Media Sender, for uploading the media object to the MADsystem (step 1).

The MAPD system includes processing capabilities in the form of a “mediaprocessing engine” and media object storage including a database and afile system (e.g., file server). When media objects are received, theyare “logged” into the database, processed if required, and stored in thefile system. As shown in step 2, a media object source URL (IMG SRC URL)is returned to the end user (originator) machine that was used to viewthe customer's web page. The IMG SRC URL is in turn sent withaccompanying form data to the destination web site (step 3).

At the destination web site, a web page is created having HTML thatcontains the IMG SRC reference. For example, the web page may describe areal estate listing and the media object may be an image of the propertybeing listed. When an end user requests to view the web page (a hit tothe web page occurs), HTML containing the IMG SRC URL is delivered tothe end user's (requestor=s) computer from the destination web site. Themedia object itself is delivered separately from the MAPD system but atthe same time the destination web page is served (step 5).

Some customers may prefer to host media objects on their own servers. Inthis instance, a MAD system mirroring service is used. Referring to FIG.3, the media object mirroring service entails the following steps:

1. A media object is submitted by an end user (originator) draggingcontent into a MAPD system customer's web page. Media object ID data isalso collected.

2. The media object may be pre-processed, such as converted, reduced,enhanced, etc.

3. The media object is uploaded to the MAPD system with ID information.

4. The media object and data are received by the MAPD system and thedata is stored in a database while the media object is stored on a fileserver.

5. A request is placed in the distribution queue notifying the serversthat additional processing and preparation may then be required prior tosending.

6. The media object is processed in accordance with a profile thatrepresents the viewing requirements of the destination web sites and theprocessed media object is distributed to the customer's web server(second location) or to other web servers (e.g., customer affiliatelocations) approved by the customer.

7. The media object and ID information are received by the secondlocation and are processed by the customer's servers so that the IDinformation is automatically stored in a database and the media objectis stored in accordance with predetermined instructions per the secondlocation.

8. When an end user (requestor) hits the customer's web sites thatcontain media objects from the MAPD system, the web sites and mediaobjects are served from the customer's web server.

Transaction flow for the mirror service may be further appreciated withreference to FIG. 4. As in the case of the hosting service, transactionflow for the mirroring service begins with a MAPD system customer webpage having embedded in it the prepare and post tool, represented as amedia object identifier. The end user drops a selected media object intothe media object identifier and clicks on the Send button, sending themedia object to the MAPD system central server (step 1). A return codeis returned (step 2) to the COM component indicating whether or notsubmission has been successful.

On central servers within MAPD system, the media object is processed inaccordance with a stored customer profile. The media object is then sentdirectly (step 3) to the customer's web site servers, where it isstored. A return code is returned (step 4) to the MAPD system indicatingsuccess or failure of media object transfer to the destination websites.

As in the case of the hosting service, at each destination web site, aweb page is created having HTML containing the IMG SRC reference.However in most mirroring scenarios, different from the hosting service,when an end user (requester) hit to the web page occurs, the web pageand the media object are delivered directly from the customer's servers(steps 5 and 6).

Another implementation of mirroring may not send the media object itselfto the MAPD system customer or customer affiliate locations. Other datathat references the media object, such as the IMG SRC URL, may bedistributed directly to the customer's servers and automaticallyintegrated with web page data. The URL in hosting is returnedimmediately to the web page where the submission originates. The URL inmirroring is forwarded to another server (second location) not relatedto the web page where the submission originates. In this instance, themedia object will be served from the MAPD system.

Referring to the real estate industry example stated earlier, FIG. 5, isan example of a realty web page featuring the described prepare and postfunctionality of the MAPD system. The end user (originator) drags anddrops photos into media object identifiers and selects appropriatecaptions for the media object, e.g., living room, family room, etc. Thecaptions may be typed in or selected from menus. The end user alsosupplies identifying information, in this instance the multiple listingservice number. When the end user clicks the Send Photos button, themedia objects are processed and transported immediately according to theconfiguration of the tool and in accordance with the hosting service orthe mirroring service previously described.

There are three ways media objects become associated with a media objectidentifier. The first is through a “drag and drop” behavior where theuser clicks on a media object to select the one they want to submit. Themedia object is then dragged to the media object identifier. Releasingthe mouse button associates the media object with the media objectidentifier. This behavior is allowed in web browsers that support dragand drop functionality. The prepare and post tools enable these browsersto accept media objects via drag and drop by providing the media objectidentifier as an ActiveX component.

The second way to associate a media with the media object identifier isto click on the media object identifier to browse for media objects,then select the media object of choice. This method is made availablefor web browsers where the media object identifier needs to be a pureJava component. (Such as “signed applet browsers” like NetscapeNavigator). In this instance, the user may be asked to choose a mediaobject in a similar manner as when choosing a file to be opened, eitherby graphical navigation or by specifying a path name. For example, aprompt associated with the media object identifier may be displayedprompting the user to click within the media object identifier. Clickingwithin the media object identifier brings up a browse dialog. Using thebrowse dialog, the user selects the desired media object, which is thenplaced in the media object identifier. The prepare and post tools willgenerate a visual representation or thumbnail of the media object, afeature currently not available in signed applet browsers.

A variation of the second way to associate a media object with the mediaobject identifier involves support for older browser versions, alsoreferred to as minimal browsers. Browsers in this category includeversions 2.X and 3.X. Also considered part of the minimal browsercategory are all browsers used on the Macintosh platform. To accommodatecomplex file sending requirements from within minimal web browsers, theMAPD system implements media object sending through the alternate HTTPchannel using the HTML<FILE>element. Once the end user (originator)clicks to send the media object, it is converted to a multi-part mimeformat for sending to the MAPD system central servers.

The prepare and post tool also supports a batch interface, allowing aplurality of media objects to be batched and submitted simultaneously.Most users who are using media objects work with several media objectsat the same time versus one media object at a time. Therefore, it isdesirable to submit 5, 10 or 25 media objects for processing anddistribution at one time for efficiency without having to repeat stepsfor each of the media objects. An example is a professional photographerwho may need to submit several media objects at the same time to severaldestination web sites. Quickly clicking and dragging a plurality ofmedia objects for submission with the MAPD system is as easy andefficient as submitting one media object.

The description of the present invention thus far has discussed that amedia object can be obtained from a single source or from multipleorigination sources and that a media object can be transmitted to asingle destination and to multiple destinations. Thepoint-to-multi-point distribution is a key advantage of the presentinvention. This multi-point distribution may be accomplished usingdistribution lists stored at MAPD system central servers. Distributionlists stored within the MAPD database provide a way for MAPD systemcustomers to specify which of their affiliate web sites get mirroredcopies of images submitted through the mirror service distributeddirectly to them. In technical terms, a distribution list is a namedentity that binds a group of destination web sites with a customer viathe mirror service. When a media object arrives from a customer on themirror service, the MAPD system uses the customer's named distributionlist to establish which web site servers (i.e., customer affiliatelocations) receive copies of the media object. FIG. 12 shows thispoint-to-multi-point distribution relationship as it is managed by theservice link and the distribution list, as will be described hereinbelow.

Each entity in a distribution list has an associated client profile thatidentifies the remote servers for the destination web sites, thedelivery method and any number of processing filters to apply to themedia object before sending. Filters are used to control the attributesof media object content delivered to clients, which are tied to thecustomer profiles. Filters can also be employed to increasefunctionality within the MAPD system architecture. The attributes mayinclude dimensions, quality and type of media object delivered (i.e.,slide show, video) etc. Filters are applied to inbound media objects oroutbound media objects or both and are used for both the MAPD systemhost and mirror service.

More particularly, filters may be associated with both services andclients. Service filters are applied as the media object is received.For mirror services, the service filter is applied as the media objectarrives, before it is stored. As the mirror service distributes themedia object to clients, the appropriate filter for each client isapplied before the media object is sent. For example, a particularmirror service may convert all images to 320.times.200 jpeg beforestoring them, and then convert those to the specific requirements ofeach client on its distribution list prior to transporting the images.For the hosting service, the service filter is applied as the mediaobject is received, and then the appropriate client filter is applied tothe result before the media object is stored. Clients and services canshare filters. If no filters associated with a given service or clienthandle a particular file type, then media objects with that file typeare not converted for that service or client.

Depending on the particular service, image processing may be performedprimarily at the client using the prepare and post tool, primarily at aMAPD system central server, or may be performed at both, some at theclient and some at the MAPD system central server. In the case of thehost service, for example, image requirements may be specified within aparticular instance of the prepare and post tool as it is integratedinto the web page of a particular customer. Processing the image withinthe prepare and post tool avoids unnecessary data transfer. In the caseof the mirror service, for example, more than one processed image may beproduced from the original image submission. Image processing maytherefore be performed primarily at the central server. Nevertheless,basic sizing and resampling may be performed at the client, avoiding thecircumstance in which a novice user attempts to upload a huge imagefile, causing their network connection to “choke.”

Although media processing will often involve sizing and formatting ofimages, any of various kinds of media processing may be performed by theMAPD system media processing engine, for example enhancements andeffects, text and graphic layering, image stitching, streaming videoencoding, producing zoomable images, cropping, rotating, etc.

For instance, in one embodiment, resizing and format conversion of stillimages may be performed on either the client or central server. Inanother embodiment video image encoding may be performed on either theclient or central server. In still another embodiment, still images areresized by determining on the central server a maximum still image sizefor all destination web sites such that the still images are resized nolarger than the maximum size on the central server. In this case,resizing of the image may also be performed on the client.

Furthermore, although the MAPD systems have been described as having acentral server, any suitable server architecture may be used to supportMAPD system services. One type of architecture that is complementary toMAPD system services is a distributed server architecture and globalcontent distribution service offered by Akamai Technologies, Inc. ofCambridge, Mass. under the name Freeflow™. The Freeflow contentdistribution method allows content providers to ensure rapid access totheir sites without needing to maintain burdensome and expensive contentdistribution infrastructure, using a global network of specializedservers and software that controls how content is distributed throughoutthe network. Rapid access is achieved by moving bandwidth-intensivecontent closer to the user. Web site performance is optimized bymigrating content according to its popularity while taking into accountchanging network conditions and fluctuations in traffic. The MAPD systemmay optionally pass information to this distributed server environmentor others, as needed, in order to optimize delivery of the media contentthe MAPD system creates.

Referring to FIG. 6 therefore, a block diagram of the MAPD systemnetwork imaging architecture is shown. A MAPD system Media Acquisitionand Distribution layer (MAPD system central server) provides for mediaobject processing in accordance with customer profiles, and formulti-point distribution as described. Above the MAPD system MediaAcquisition and Distribution layer may be various service layersincluding zoomable images, streaming video encoding, image stitching,slide shows, text and graphic layering, enhancement and effects, sizingand formatting. The architecture is easily extended by added newservices as needed. Below the MAPD system Media Acquisition andDistribution layer is the optional distributed server infrastructure,which may be a global hosting infrastructure such as that of Akamai orany other advantageous server infrastructure partner.

Recognizing that any of various server infrastructures may be used, theMAPD system central hardware architecture in accordance with anexemplary embodiment of the invention will be described. Referring toFIG. 7, an example of how the MAPD system mirroring system hardwarecould be partitioned is detailed. A cluster organization is followedthat uses three clusters, an inbound cluster, a file server cluster andan outbound cluster. The file server cluster is attached to a MAPDsystem database, or repository. Web submissions from the MAPD systemprepare and post tool are received by the inbound cluster. Within theinbound cluster, the MAPD system repository is consulted in order toform a distribution request, which is sent to a distribution queue atthe outbound cluster through a remote interface. Within the outboundcluster, distribution requests are polled and processed by picking upitems from the distribution queue and building a distribution list basedon the corresponding customer's profile. For each destination in thedistribution list, a distribution server within the outbound clustermakes a socket connection to the second location and delivers the mediaobject.

Because of the ability to have a media object sent to multipledestinations, the number of outbound transactions is potentially fargreater than the number of inbound transactions. To facilitate thetransfer of media objects, inbound media processing is separated fromoutbound media processing. This separation is accomplished by the MAPDsystem distribution queue. In an exemplary embodiment, the MAPD systemdistribution queue is a runtime Remote Method Invocation (RMI) objectshared between multiple MAPD systems and outbound distributionprocessors. Referring more particularly to FIG. 8, when a submissionarrives for the mirror service, it is received by an inbound mirrorprocessor. The inbound mirror processor stores the submission within theMAPD system repository and adds a distribution object to thedistribution queue. The outbound media distributor constantly polls thedistribution queue for available items and when one is available,removes it from the queue and carries out the distribution. A singleinbound submission to the mirror service typically results in multipledistributions to customer affiliate locations, since the purpose of themirror service is to allow MAPD system customers to distribute media tothat customer's affiliates using a distribution list. Once the outboundmedia distributor pulls an item off the distribution queue, it isresponsible to build a distribution list of all intended recipients andcarry out the transfer of media.

A ClientHoldingQueue object may be provided as a holding area fortransactions destined for a customer which is unreachable. Thesetransactions are queued as distribution objects until the customerbecomes reachable and they can be sent. A ClientHoldingQueue contains aqueue of distribution objects similar to the primary queue. It has itsown thread to process that queue and it contains the ability to ping itscustomer as a way of knowing when the customer comes back on line.ClientHoldingQueues are created whenever a normal transmission fails andthey go out of existence as soon as they are able to deliver all oftheir queued objects.

The MAPD system may be realized in two tiers (traditionalclient/server), three tiers, or, more generally, N tiers. A three-tierimplementation in accordance with an exemplary embodiment of theinvention is illustrated in FIG. 9. The three-tier partitioning includesa client tier, an application tier and a database tier. Beside tierboundaries, also identified are IP (internet protocol) boundaries.Communication across IP boundaries occurs, for example, through theInternet using the Internet Protocol (IP). A vertical IP boundaryseparates client (sources) from consumers (destinations). A horizontalIP boundary separates (browser-based) client from servers.

In operation, submission tools (prepare and post) are used to submitmedia to a central server where the media objects are processed asnecessary, stored, and distributed, either by hosting or mirroring. Inthe case of mirroring, the outbound servers send the media object to amirrored client repository, causing the media object to be stored withina mirrored database. The media object is accessed from the mirroredclient repository using distribution tools and viewers, in particularweb browsers. Such access may be accomplished, for example, throughActive Server Pages (ASP) or Cold Fusion (CF) for server-side pagegeneration. In the case of hosting, the media object is accesseddirectly from the MAPD system central servers, using the same or similartechniques, for example.

Referring to FIG. 10, the principal MAPD system database system entities(tables) and their relationships are shown in accordance with anexemplary embodiment. Appendix A details the associated database tables.The Account table contains primary account information for each MAPDsystem service customer. There is only one account record for each MAPDsystem customer. The ClientProfile table contains profile informationused to control customer access to MAPD system services. A MAPD systemcustomer will typically have a single client profile, but may in someinstances have more than one customer profile, e.g., if a customer hasmultiple business units, one or more of which subscribes to MAPD systemservices. The user table defines users with access rights to accountinformation for a given customer.

The Distribution Link table is used to identify a distribution listassociated with the mirror service via a ServiceLink record. TheServiceLink.DistributionListname and the ServiceLink.ServiceLinkID areused to identify all the DistributionLink records that are targeted fora media distribution to a second location. Each DistributionLink recordidentifies a profile (DistributionLink.ProfileID) which identifies thesecond location for the distribution as well as media distributioncharacteristics (e.g., filter, applications, etc.).

The Server table identifies various MAPD systems used to process inboundtraffic, outbound traffic and media storage. The ErrorLog table recordserrors in inbound and outbound traffic processing.

The Storage Volume table contains descriptions of MAPD system centralserver volumes used for media storage. A given service uses a StorageVolume record to identify the server and volume where media will bestored. The physical and virtual paths used to identify the folderlocation for media items are identified via a StorageLink record in theStorageLink table. The StorageLink table contains physical and virtualfolder locations within a given StorageVolume. It is used foridentifying the storage location of media items within the MAPD systemcentral server.

The MediaMaster table contains one entry for each unique media elementstored in the MAPD system repository. The MediaType table identifiesclasses of media associated with MAPD system services. The Industrytable describes industries associated with MAPD system customers. It maybe based on the NAICS industry codes standard.

The Service table describes all available MAPD system services. TheServiceLink table contains associative records which identifycustomer-specific service characteristics or properties associated witha given service. The Filter table contains filter records. Each filterrecord defines activities or constraints applied to media. TheFilterLink table contains associative records which identify filtersassociated with a given customer.

Further details concerning MAPD system filters and their implementationis found in Appendix B.

As illustrated in FIG. 11 in general terms, ServiceLinks link an Accountto one or more services and ultimately, through StorageLink andStorageVolume entities, to a physical media storage location.

In the case of the mirror service, DistributionLink and ClientProfileentities control the distribution process as illustrated in FIG. 12.When a submission arrives for the mirror service, it is stored withinthe MAPD system central repository and mirrored to a customer (secondlocation) or customer affiliate locations. The second location and theaffiliate locations use MAPD system software, particularly a MAPD systemClientReceiver, to process and store media objects and data. When themedia object submission arrives the userID and password are used tolookup the associated Account (1) record. Once the account has beenidentified, the AccountId and service name (in this instance “MIRROR”)are used to find the ServiceLink (2) record associated with the accountfor the mirror service. The ServiceLink record identifies thedistribution list to mirror the submission to. Given a ServiceLinkID anda DistributionName, the DistributionLink (3) table is used to identifythe target ClientProfile (4) records used to mirror the submission. TheClientProfile (4) record contains the IP address and port of the mirrorsite (second location).

The MAPD system communicates with clients to send mirrored media objectsthrough TCP/IP sockets. A MAPD system ClientReceiver is a software agentthat sits at the customer site and waits (e.g., on a pre-defined port)for connections from the MAPD system. In an exemplary embodiment, theport is stored with the customer profile in the MAPD system repositoryand fetched by the media distributor to make the customer connection.Other delivery methods may be used instead of sockets, e.g., HTTPfilesend, FTP push, e-mail etc.

In order to effectively use the media objects, to match media objectswith customer's databases, customers need to be able to automaticallyintegrate incoming media objects (received from MAPD system distributionservers) into their existing database structures. In an exemplaryembodiment, a method shown in FIG. 13 is called when a new media objectarrives at the customer site (remote destination web site) via the MAPDsystem ClientReceiver. The ClientReceiver automatically takes the mediaobject that has been sent from MAPD system central and stores it to disk(i.e., line “String filename,” in FIG. 13). The storage location isspecified in a properties file at the customer's receiving site. TheClientReceiver also passes the information about the media object(unique ID number, sequence number, description fields, etc.) to afunction which can be modified at the customer's receiving location aswell (i.e., lines “String mediaGroupID”, “String media ExtID”, “intseqNum”, “int industry Code”, “String Desc1”, “String desc2”, and“String desc3”, in FIG. 13). The MAPD system provides a function thatcan be modified to provide the customer's own database with theinformation the MAPD system passed to the function. Once the new mediaobject has been integrated into the customer's database, it can beimmediately used in server-side page generation as a page is requestedby a web site visitor.

The function typically stores the media object information in aproprietary database (the MAPD system customer's database). The body ofthe function is commented out so the customer or the customer'saffiliate locations can fill it out with specific instructions (sourcecode to the Java class that contains this function is provided by theMAPD system). The function parameters reflect what was provided duringthe media object submission using the image submission tool.

MAPD system customers who subscribe to the “mirror” service specifytheir own servers or affiliate server locations who are approved toreceive mirrored copies of the media objects or information about themedia objects, such as IMG SRC URL, from the MAPD system. To specifywhich affiliates receive mirrored information, a distribution list isset up and a small profile is entered for each affiliate in thedatabase. The initial steps for setting up a customer for the mirrorservice are:

1. A registration form is completed that contains standard entries suchas an ID, password, full name, address, phone, e-mail, fax, etc. MAPDsystem central server uses this information to establish a servicerecord(s) for the customer account.

2. Distribution list forms are completed for each approved affiliate orcustomer server and appropriate information such as IP address to sendimages to, transformations to be performed on media objects etc. MAPDsystem central server uses this information to establish a profile foreach affiliate.

The profile contains the preferred delivery method (ClientReceiver,e-mail or FTP for the mirror service.) For delivery by theClientReceiver, the entry contains the IP address and Port for theClientReceiver.

The MAPD system ClientReceiver is provided to the customer and, in anexemplary embodiment, is a Java application or process that runs on anyplatform supporting the generic JDK 1.1 or later versions. TheClientReceiver sits on one of the customer's remote web servers or oneor more customer's affiliate locations per the customer's designation.When media objects are received by MAPD systems from the prepare andpost media submission tools, they are processed according to thecustomer's specifications as described earlier and forwarded to anyapproved affiliate locations by making a socket connection toClientReceivers installed on the customer's behalf.

In the case where the affiliate locations intended for mirrored deliverycannot install the ClientReceiver or they prefer delivery by a differentmethod, the media object submissions can alternatively be forwarded viaother methods such as FTP or by e-mail. The MAPD system is set up tospecify delivery instructions by any number of methods including but notlimited to ClientReceiver, FTP or e-mail on an affiliate-by-affiliatebasis. For example, if Customer #1 wants media objects to be sent to 3affiliates in a distribution list called “PrimaryAffiliates” (and therecan be more than one distribution list), tables at MAPD system centralmay be set up for delivery by ClientReceiver to the first affiliate, FTPto the second and e-mail to the third. The MAPD system can be configuredto have unique and varied distribution lists per the customer'sinstructions.

The following Appendices C and D describe in greater detail the programarchitecture for the Image Container (media object identifier) and COM(media sender) components used in an exemplary embodiment of theinvention. Appendix E is a general description of the ClientReceiverclass used in an exemplary embodiment of the invention.

What is claimed is:
 1. A media acquisition, processing, and distributionmethod for transferring one or more media objects to a plurality ofremote devices, comprising the following computer implemented steps:receiving, from a client device, one or more media objects that havebeen processed at said client device; in response to said receiving,processing said received one or more media objects in accordance with afirst profile associated with a first device in said plurality of remotedevices to produce first processed one or more media objects, said firstprofile containing first requirements of said first device, andprocessing said received one or more media objects in accordance with asecond profile associated with a second device in said plurality ofremote devices to produce second processed one or more media objects,said second profile containing second requirements of said seconddevice; and transmitting, by a server device to said first and seconddevices that are remote from said client device and said server device,said first and second one or more processed media objects, respectively.2. The method of claim 1, wherein said media object includes one or moreof image content, video content, and audio content.
 3. The method ofclaim 1, wherein said receiving comprises receiving, from said clientdevice, one or more media objects that have been pre-processed at saidclient device in accordance with pre-processing parameters.
 4. Themethod of claim 1, wherein said processing comprises resizing, croppingor rotating a media object.
 5. The method of claim 1, wherein saidprocessing comprises encoding a media object.
 6. The method of claim 1,wherein said processing comprises reformatting a media object.
 7. Themethod of claim 1, wherein said processing comprises encoding a mediaobject.